Functional verification systems, including hardware emulation systems and simulation acceleration systems, utilize interconnected programmable logic chips or interconnected processor chips. Examples of systems using programmable logic devices are disclosed in, for example, U.S. Pat. No. 6,009,256 entitled “Simulation/Emulation System and Method,” No. 5,109,353 entitled “Apparatus for emulation of electronic hardware system,” No. 5,036,473 entitled “Method of using electronically reconfigurable logic circuits,” No. 5,475,830 entitled “Structure and method for providing a reconfigurable emulation circuit without hold time violations,” and No. 5,960,191 entitled “Emulation system with time-multiplexed interconnect.” U.S. Pat. Nos. 6,009,256, 5,109,353, 5,036,473, 5,475,830, and 5,960,191 are incorporated herein by reference. Examples of hardware logic emulation systems using processor chips are disclosed in, for example, U.S. Pat. No. 6,618,698 “Clustered processors in an emulation engine,” No. 5,551,013 entitled “Multiprocessor for hardware emulation,” No. 6,035,117 entitled “Tightly coupled emulation processors,” No. 6,051,030 entitled “Emulation module having planar array organization,” and No. 7,739,093 entitled “Method of visualization in processor based emulation system.” U.S. Pat. Nos. 6,618,698, 5,551,013, 6,035,117, 6,051,030, and 7,739,093 are incorporated herein by reference.
Functional verification systems help to shorten the time it takes to design a customized application specific integrated circuits (ASICs) by allowing designers to emulate the functionality of the ASIC before a production run has begun. Functional verification systems help to ensure ASICs are designed correctly the first time, before a final product is produced.
In some instances, functional verification systems comprise emulators in communication with a target system to emulate at least a portion of a hardware design. The target system comprises real-world hardware operating at near real-time clock frequencies. The target system can be thought of as the system in which the electronic design being verified in the emulator will be installed once manufactured. The ability to run the emulated design under test in the electronic system the manufactured device will eventually be installed within provides significant advantages. For example, being able to run the emulated design in the system in which the final integrated circuit will be installed can provide additional confidence in the verification process. In addition, once the design is debugged, the ability to run the design in the system for which it will be installed allows further development of the target system to take place. For example, such concurrent use allows development of firmware of the final system.
The emulator comprises ASICs and/or FPGAs used to emulate a portion of the hardware design. Communication between the target system and the emulator enables verification of a hardware design in near real-time.
The emulator and target system are in communication via connections such as Ethernet or optical fiber. However, these connections need to be periodically tested for failure. For example, an emulator emulating a hardware design may be in communication with a target system. The functional verification system may indicate that the emulated hardware design does not operate as expected. The hardware designer may then wish to check the target connection because he suspects the problem lies with the target connections, rather than with the hardware design. Also, after maintenance on the functional verification system, such as replacing the target connections or target system, a field services engineer (FSE) may need to check the target connections to ensure they are working properly.
In current systems, testing the connections between emulators and the target system presents two challenges. First, domains comprising ASICs or FPGAs implement test logic to send test signals across the connection. This results in the domain being taken “offline,” during which time it cannot be used to emulate the hardware design. Second, testing the connection requires swapping out the cables between the emulator and the target system. This is because the test logic may return an error. However, it is not possible to tell whether the error results from a fault with the connection or whether the logic has been corrupted at the end points, the domains or the target system.
Although the present systems for target diagnostics are useful to a degree, there still exists a need in the field for improved systems for target diagnostics. Thus, for at least these reasons there is a need for an improved system for concurrent target diagnostics that enable the domains to remain in use while testing the target connection. There is also a need for a target diagnostic system and method that does not require manual swapping of the target connections.